Payment application framework

ABSTRACT

A payment application framework may include metaphors and constraints. The metaphors may be associated with actors and objects that are part of the payment transactions. The constraints may include rules and parameters that may be used to process the payment transactions.

FIELD

The present application relates generally to the field of electronicpayments and, in one specific example embodiment, a framework forpayment application development.

BACKGROUND

Electronic payment systems have evolved over the last several years withthe introduction of services by different payment providers orfacilitators. These payment facilitators may use different proprietaryprogramming interfaces to develop payment applications. Each applicationmay be developed independently of one another. This approach can beproblematic as new features and requirements may have to be implementedindividually depending on the service. This approach may result inunnecessary duplicate efforts and may delay time to bring new paymentapplications/services to the market.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated by way of example and not limitation inthe figures of the accompanying drawings in which:

FIG. 1A illustrates a network diagram depicting a system, according toan example embodiment, having client-server architecture.

FIG. 1B is a block diagram illustrating example applications that mayassociated with the system of FIG. 1A, in accordance with some exampleembodiments.

FIGS. 1C-1D illustrate example tables that may be associated with adatabase included in the system of FIG. 1A, in accordance with someexample embodiments.

FIG. 2 is a block diagram illustrating a high level view of a paymentapplication framework, in accordance with some example embodiments.

FIG. 3A is a diagram illustrating an application of the metaphors in apayment scenario, in accordance with some example embodiments.

FIG. 3B is a diagram illustrating another application of the metaphorsin a payment scenario, in accordance with some example embodiments.

FIG. 4A is a diagram that illustrates phases that are included in themetaphors, in accordance with some example embodiments.

FIG. 4B is a diagram that illustrates an example of the phases wherethere is a pre-approval, in accordance with some example embodiments.

FIG. 5 is a flow diagram that illustrates an example of an approvalflows, in accordance with some example embodiments.

FIG. 6 is a flow diagram that illustrates an example of a pre-approvalflow, in accordance with some example embodiments.

FIG. 7 illustrates an example of a send money scenario using the paymentapplication framework, in accordance with some example embodiments.

FIG. 8 illustrates an example of a checkout scenario using the paymentapplication framework, in accordance with some example embodiments.

FIGS. 9A-B illustrate diagrams that illustrate examples of parallelpayments and chained payments, in accordance with some exampleembodiments.

FIG. 10 illustrates a diagrammatic representation of a machine in theform of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed, according to an example embodiment.

DETAILED DESCRIPTION

For some example embodiments, methods and systems for developing paymentapplications using a payment application framework are disclosed. Thepayment application framework may include metaphors and constraints. Themetaphors may include actors and objects. The actors and objects aresome of the components of the payment transactions. The constraints mayinclude rules that may be followed to process the payment transactions.

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of example embodiments. It will be evident, however, toone skilled in the art that the present invention may be practicedwithout these specific details.

In example embodiments, a computer system (e.g., a client machine,server machine etc) configured by an application may constitute a“module” that is configured and operates to perform certain operationsas described herein. Accordingly, the term “module” should be understoodto encompass a tangible entity, be that an entity that is physicallyconstricted, permanently configured (e.g., hardwired) or temporarilyconfigured (e.g. programmed) to operate in a certain manner and toperform certain operations described herein.

Overview

A payment application framework may allow development of paymentapplications using a set of standards. The payment applications maycover different payment scenarios including, for example, checkout, sendmoney, request money, split payment, mass payment, recurring paymentsand remittances. The example scenarios may involve one or more sendingor paying parties and one or more receiving parties. The paymenttransactions may be associated with the transfer of funds in one or morecurrencies. The payment transactions may be associated with the transferof valuable items or merchandises. For example, the payment transactionsmay also be associated with points, mileages, rewards, or any tangibleor intangible objects or services that are perceived as having somemeasureable values by the one or more sending parties and the one ormore receiving parties.

A payment application framework may include metaphors and constraints.There may be flows and services used with or applied to the metaphorsand the constraints. Using the payment application framework, thedevelopment of new payment applications may be simplified.

Platform Architecture

FIG. 1A illustrates a network diagram depicting a system 100 havingclient-server architecture, according to an example embodiment. Asystem, in the example form of a network-based system 112, providesserver-side functionality, via a network 114 (e.g., the Internet, apublic or private telephone, wired or wireless network, a privatewireless network using technologies such as Bluetooth or IEEE 802.11x orother networks) to one or more clients. FIG. 1A illustrates, forexample, a web client 116 (e.g., a browser, such as the INTERNETEXPLORER® browser developed by MICROSOFT®) executing on client machine120. A device application 117 may execute on a client machine 121. Aprogrammatic client 118 may execute on client machine 122. Each of theclient machines 120-122 may be referred to as a network-based machine.Further, while the system 100 shown in FIG. 1A employs client-serverarchitecture, embodiments are of course not limited to such anarchitecture, and could equally well find applications in a distributed,or peer-to-peer, architecture system.

The client machines 120-122, may include a mobile device, a palmtopcomputer, a laptop computer, a desktop computer, a personal digitalassistant, a cellular telephone, a communications device, a wirelesstelephone, a land-line telephone, a control system, a camera, a scanner,a television, television cable, a telephone with a web browser, afacsimile machine, a printer, a pager, and/or a personal trusted device.The client machines 120-122 may include a card, such as a smart card, amagnetic card, and/or a key card. The client machines 120-122 mayinclude a telephone or any device capable of Short Messaging Service(SMS) messaging, multimedia messaging service (MMS) messaging and/orgenerating audio tones, such as dual-tone multi-frequency (DTMF) tones.

The client machines 120-122 may be browser-enabled. The client machines120-122 may engage in an interactive message and/or open communicationsession, such as SMS, electronic mail, Extensible Hypertext MarkupLanguage (xHTML), Wireless Application Protocol (WAP), web, interactivevoice response (IVR) and/or other mobile interfaces. The communicationsession between the client machines 120-122 and the network-based system112 may involve multiple technology modalities. For example, a user ofthe client machines 120, 121 or 122 may engage the network-based system112 via SMS and receive a responsive communication as an SMS with anembedded hyperlinked URL directing the client machines 120, 121, or 122to a WAP or web page. A hyperlinked URL may be delivered directly to theclient machines 120-122 from the application server(s) 128 and may beused to access a web site or a micro-browser, such as a WAP site. Theclient machines 120-122 may enable mobile videophone communications,digital television signals, and/or digital radio signals. The clientmachines 120-122 may include a receiver to receive near fieldcommunications.

Turning specifically to the network-based system 112, an ApplicationProgram Interface (API) server 124, and a web server 126 may be coupledto, and may provide programmatic interface and web interface to one ormore application servers 128. The client machines 120-122 may use one ormore of these interfaces to access the application server(s) 128.

For example, the web client 116 may access the application server(s) 128via a web interface supported by the web server 126. The web interfacemay include a web browser or any micro-browser, such as xHTML or WAP.Similarly, the programmatic client 118 may access the various servicesand functions provided by the application server(s) 128 via theprogrammatic interface provided by the API server 124 and/or via the webinterface provided by the web server 126. For an additional embodiment,an application supported by one or more applications of the applicationserver(s) 128 may be downloadable to the client machines 120-122.

The client machines 120-122 may host the interface associated with theone or more applications of the application server(s) 128. The interfaceon the client machines 120-122 may be an API interface, an SMSinterface, a web interface, and/or an IVR interface. Consumer wirelessdevice platforms, such as Java 2 Platform Micro Edition (J2ME), J2SE andJ2EE allow developers to use Java and a wireless toolkit to createapplications and programs for the client machines 120-122. The J2MEinterface may include an API for the client machines 120-122. Theapplication of the programmatic client 118 may also access the network114 using, for example, Binary Runtime Environment for Wireless (BREW).

The device application 117 executed on the client machine 121 may accessthe application server(s) 128 via the web interface of the web server126. The device application 117 may be selected on the client machine121 and launched in a background. The device application 117 mayadditionally or alternatively access the server(s) 128 via theprogrammatic interface of the API server 124. In an embodiment, thedownloaded application described herein may include the deviceapplication 117.

The application server(s) 128 may host one or more administrationmodule(s) 130 and one or more payment module(s) 132. The applicationserver(s) 128 are, in turn, shown to be coupled to one or more databaseservers 134 that facilitate access to one or more databases 136. Theaccount administration module(s) 130 may provide for administration ofvarious accounts, as discussed in more detail herein.

A third party application 138 executing on a third party server 140 mayoffer goods and services to users of the client machines 120-122. Thethird party application 138 may have programmatic access to thenetwork-based system 112 via the programmatic interface provided by theAPI server 124. The third party application 138 may be associated with avendor, a merchant, or any organizations that may conduct transactionswith the users of the client machines 120-122. For some exampleembodiments, the third party application 138 may be associated with anonline marketplace (e.g., eBay, Inc. of San Jose, Calif.).

The payment module(s) 132 may provide a number of payment services andfunctions to the users of the client machines 120-122. The paymentmodule(s) 132 may allow the users to accumulate value (e.g., in acommercial currency, such as the U.S. dollar, or a proprietary currency,such as “points”) in accounts, and then later to redeem the accumulatedvalue via several possible avenues. The payment module(s) 132 may alsoextend credit to a user and/or may also have access to other fundingsources to complete transactions. Examples of the funding sourcesinclude a credit card, a bank account, and/or a credit line. The paymentmodule(s) 132 may operate as a money transmitter.

A third party associated with the third party application 138 mayconduct transactions with a user and may receive information from thepayment module(s) 132. The information may include information regardingan order for a product, a service, a gift, a donation, etc. Theinformation may also include shipment address specified by the user andpayment status including payment confirmation. The payment module(s) 132may secure financial information of the user with respect to the thirdparty.

The client machine 120, 121, or 122 may host the interface associatedwith the payment module(s) 132 of the application server(s) 128. The webclient 116, the device application 117, and/or the programmatic client118 may be associated with the account management module(s) 130 and/orthe payment module(s) 132.

The payment module(s) 132 may also be implemented as a standalonesoftware program, which does not necessarily have networkingcapabilities. For this embodiment, the client machines 120-122 may bedirectly connected to the payment module(s) 132, without using thenetwork 114.

The payment module(s) 132 may have access to the database 136 which maybe coupled to database server(s) 134. The database 136 may include useraccount information. The user account information may include paymentinformation, credit card information, checking account information,address information, etc.

The web client 116, the device application 117, and/or the programmaticclient 118 may operate a program supported by the one or more databaseserver(s) 134. The database server(s) 134 may support one or moreaccount information links on a user interface of the client machines120-122, for example, using the web client 116. By accessing thedatabase server(s) 134, the user may add, amend or delete own accountinformation including, for example, shipment address, payment method,etc.

The network 114 may include a mobile telephone network, a wireless widearea network (WWAN), a wired telephone network, a wireless local areanetwork (wireless LAN or WLAN), a wireless Metropolitan Area Network(MAN), and/or a wireless personal area network (PAN) (e.g., a Bluetooth®network). Other network-based technologies that may be used to connectinclude PON, VSAT satellite, Micro-impulse Radar, Radio Frequencyidentification (RFID), Ultra-Wide Band, and/or Infrared. The clientmachines 120-122 may connect to the web using mobile internet exchangeprotocol such as, for example, Wireless Application Protocol (WAP)and/or Hypertext Transport Protocol (HTTP).

Marketplace Applications

FIG. 1B is a block diagram illustrating multiple applications 130 and132 that, in one example embodiment, are provided as part of thenetworked system 112. The applications 130 and 132 may be hosted ondedicated or shared server machines (not shown) that are communicativelycoupled to enable communications between server machines. Theapplications 130 and 132 themselves are communicatively coupled (e.g.,via appropriate interfaces) to each other and to various data sources,so as to allow information to be passed between the applications or soas to allow the applications 130 and 132 to share and access commondata. The applications 130 and 132 may furthermore access one or moredatabases 136 via the database servers 134.

The networked system 112 may provide a number of publishing, listing andprice-setting mechanisms whereby a seller may list (or publishinformation concerning) goods or services for sale, a buyer can expressinterest in or indicate a desire to purchase such goods or services, anda price can be set for a transaction pertaining to the goods orservices. To this end, the marketplace applications 130 are shown toinclude at least one publication application 140 and one or more auctionapplications 142 which support auction-format listing and price settingmechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverseauctions etc.). The various auction applications 142 may also provide anumber of features in support of such auction-format listings, such as areserve price feature whereby a seller may specify a reserve price inconnection with a listing and a proxy-bidding feature whereby a biddermay invoke automated proxy bidding.

A number of fixed-price applications 144 support fixed-price listingformats (e.g., the traditional classified advertisement-type listing ora catalogue listing) and buyout-type listings. Specifically, buyout-typelistings (e.g., including the Buy-It-Now (BIN) technology developed byeBay Inc., of San Jose, Calif.) may be offered in conjunction withauction-format listings, and allow a buyer to purchase goods orservices, which are also being offered for sale via an auction, for afixed-price that is typically higher than the starting price of theauction.

Store applications 146 allow a seller to group listings within a“virtual” store, which may be branded and otherwise personalized by andfor the seller. Such a virtual store may also offer promotions,incentives and features that are specific and personalized to a relevantseller.

Reputation applications 148 allow users that transact, utilizing thenetworked system 112, to establish, build and maintain reputations,which may be made available and published to potential trading partners.Consider that where, for example, the networked system 112 supportsperson-to-person trading, users may otherwise have no history or otherreference information whereby the trustworthiness and credibility ofpotential trading partners may be assessed. The reputation applications148 allow a user, for example through feedback provided by othertransaction partners, to establish a reputation within the networkedsystem 112 over time. Other potential trading partners may thenreference such a reputation for the purposes of assessing credibilityand trustworthiness.

Personalization applications 150 allow users of the networked system 112to personalize various aspects of their interactions with the networkedsystem 112. For example a user may, utilizing an appropriatepersonalization application 150, create a personalized reference page atwhich information regarding transactions to which the user is (or hasbeen) a party may be viewed. Further, a personalization application 810may enable a user to personalize listings and other aspects of theirinteractions with the networked system 112 and other parties.

The networked system 112 may support a number of marketplaces that arecustomized, for example, for specific geographic regions. A version ofthe networked system 112 may be customized for the United Kingdom,whereas another version of the networked system 112 may be customizedfor the United States. Each of these versions may operate as anindependent marketplace, or may be customized (or internationalized)presentations of a common underlying marketplace. The networked system112 may accordingly include a number of internationalizationapplications 152 that customize information (and/or the presentation ofinformation) by the networked system 112 according to predeterminedcriteria (e.g., geographic, demographic or marketplace criteria). Forexample, the internationalization applications 152 may be used tosupport the customization of information for a number of regionalwebsites that are operated by the networked system 112 and that areaccessible via respective web servers 126.

Navigation of the networked system 112 may be facilitated by one or morenavigation applications 154. For example, a search application (as anexample of a navigation application) may enable key word searches oflistings published via the networked system 112. A browse applicationmay allow users to browse various category, catalogue, or inventory datastructures according to which listings may be classified within thenetworked system 112. Various other navigation applications may beprovided to supplement the search and browsing applications.

In order to make listings, available via the networked system 112, asvisually informing and attractive as possible, the marketplaceapplications 130 may include one or more imaging applications 156utilizing which users may upload images for inclusion within listings.An imaging application 156 also operates to incorporate images withinviewed listings. The imaging applications 156 may also support one ormore promotional features, such as image galleries that are presented topotential buyers. For example, sellers may pay an additional fee to havean image included within a gallery of images for promoted items.

Listing creation applications 158 allow sellers conveniently to authorlistings pertaining to goods or services that they wish to transact viathe networked system 112, and listing management applications 160 allowsellers to manage such listings. Specifically, where a particular sellerhas authored and/or published a large number of listings, the managementof such listings may present a challenge. The listing managementapplications 160 provide a number of features (e.g., auto-relisting,inventory level monitors, etc.) to assist the seller in managing suchlistings. One or more post-listing management applications 162 alsoassist sellers with a number of activities that typically occurpost-listing. For example, upon completion of an auction facilitated byone or more auction applications 142, a seller may wish to leavefeedback regarding a particular buyer. To this end, a post-listingmanagement application 162 may provide an interface to one or morereputation applications 148, so as to allow the seller conveniently toprovide feedback regarding multiple buyers to the reputationapplications 148.

Dispute resolution applications 824 provide mechanisms whereby disputesarising between transacting parties may be resolved. For example, thedispute resolution applications 164 may provide guided procedureswhereby the parties are guided through a number of steps in an attemptto settle a dispute. In the event that the dispute cannot be settled viathe guided procedures, the dispute may be escalated to a third partymediator or arbitrator.

A number of fraud prevention applications 166 implement fraud detectionand prevention mechanisms to reduce the occurrence of fraud within thenetworked system 112.

Messaging applications 168 are responsible for the generation anddelivery of messages to users of the networked system 112, such messagesfor example advising users regarding the status of listings at thenetworked system 112 (e.g., providing “outbid” notices to bidders duringan auction process or to provide promotional and merchandisinginformation to users). Respective messaging applications 168 may utilizeany number of message delivery networks and platforms to delivermessages to users. For example, messaging applications 168 may deliverelectronic mail (e-mail), instant message (IM), Short Message Service(SMS), text, facsimile, or voice (e.g., Voice over IP (VoIP)) messagesvia the wired (e.g., the Internet), Plain Old Telephone Service (POTS),or wireless (e.g., mobile, cellular, WiFi, WiMAX) networks.

Merchandising applications 170 support various merchandising functionsthat are made available to sellers to enable sellers to increase salesvia the networked system 112. The merchandising applications 170 alsooperate the various merchandising features that may be invoked bysellers, and may monitor and track the success of merchandisingstrategies employed by sellers.

The networked system 112 itself, or one or more parties that transactvia the networked system 112, may operate loyalty programs that aresupported by one or more loyalty/promotions applications 172. Forexample, a buyer may earn loyalty or promotions points for eachtransaction established and/or concluded with a particular seller, andbe offered a reward for which accumulated loyalty points can beredeemed.

Payment framework applications 174 are responsible for the interactionwith the a payment application developer to enable developing paymentapplications. The payment framework applications 175 may performoperations that enable associating components of payment transactionswith at least some sets of predefined tools including those associatedwith a sending entity (or sender), a receiving entity (or receiver), apayment system (or a payment facilitator) along with flows that enabletransfer of values from the sender to the receiver. The paymentframework applications 174 may be able to access information stored inthe databases 136.

Data Structures

FIG. 1C is a high-level entity-relationship diagram, illustratingvarious tables 180 that may be maintained within the databases 136, andthat are utilized by and support the applications 130 and 132. A usertable 181 contains a record for each registered user of the networkedsystem 112, and may include identifier, address and financial instrumentinformation pertaining to each such registered user. A user may operateas a seller, a buyer, or both, within the networked system 112. In oneexample embodiment, a buyer may be a user that has accumulated value(e.g., commercial or proprietary currency), and is accordingly able toexchange the accumulated value for items that are offered for sale bythe networked system 112.

The user table 181 may be associated with one or more of the sender andthe receiver that may be used by the payment framework applications 175described in FIG. 1B.

The tables 180 also include an items table 182 in which are maintaineditem records for goods and services that are available to be, or havebeen, transacted via the networked system 112. Each item record withinthe items table 182 may furthermore be linked to one or more userrecords within the user table 181, so as to associate a seller and oneor more actual or potential buyers with each item record.

A transaction table 183 contains a record for each transaction (e.g., apurchase or sale transaction) pertaining to items for which recordsexist within the items table 182.

An order table 187 is populated with order records, each order recordbeing associated with an order. Each order, in turn, may be with respectto one or more transactions for which records exist within thetransaction table 183.

Bid records within a bids table 188 each relate to a bid received at thenetworked system 112 in connection with an auction-format listingsupported by an auction application 142. A feedback table 184 isutilized by one or more reputation applications 148, in one exampleembodiment, to construct and maintain reputation information concerningusers. A history table 185 maintains a history of transactions to whicha user has been a party. One or more attributes tables 186 recordattribute information pertaining to items for which records exist withinthe items table 182. Considering only a single example of such anattribute, the attributes tables 916 may indicate a currency attributeassociated with a particular item, the currency attribute identifyingthe currency of a price for the relevant item as specified in by aseller. Payment framework table 190 may include information that may beused by the payment framework applications 174.

FIG. 1D provides further details regarding a payment framework tablethat is shown in FIG. 1C to be maintained within the databases 136. Asillustrated, the payment framework table 190 may include multiplefields. Each of the fields may be associated with some user informationsuch as, for example, metaphors 191, objects 192, and constraints 193,as described in more details below.

Payment Application Framework

For some example embodiments, payment applications that are developedusing the payment application framework generally enable transfer ofvalues (e.g., funds, reward points, etc.) from an account associatedwith one party (referred to as a sender) to another account associatedwith another party (referred to as a receiver). To perform the valuetransfer, execution of the payment applications may be based on one ormore approval flows. This may require having access or the rights toinitiate these approval flows and to use the services of a paymentfacilitator. One example of a payment facilitator is the servicesoffered by PayPal, Inc. of San Jose, Calif. Having access may notinclude having approval to transfer the values out of the sender'saccount. Having approval may implicitly include having access. This maybe applicable in pre-approval situations, as described below.

The payment applications may generate pay requests. The pay requests arerelated to the payment transactions. The pay requests includeinstructions provided to the payment facilitator (or payment processinglogic in the payment facilitator) to set up or define one or morepayment transactions. For example, in a split payment scenario, a singlepay request can refer to a single payment transaction or multiplepayment transactions. The pay requests may be viewed as tools used bythe developers to set up the payment transactions. The pay requests maybe transparent to the senders and the receivers. The paymenttransactions may be more visible and recognizable to the senders and thereceivers.

FIG. 2 is a block diagram illustrating a high level view of a paymentapplication framework, in accordance with some example embodiments.Payment application framework 200 may be used to develop paymentapplications 220 which may form one or more payment module(s) 132described in the system 100. The payment application framework 200 mayinclude a constraint library 205 and a metaphor library 210. The paymentapplication framework 200 may also enable the payment applications 220to receive customized information 215. The customized information 215may include information that modifies, replaces, or complements theinformation included in the constraint library 205 and/or the metaphorlibrary 210.

For some example embodiments, the metaphor library 210 may includemetaphors that represent high level views of more detailedpayment-related concepts. The metaphors may be designed to be simple andeasy to understand and to enable consistency across different types ofpayment applications 220. For some example embodiments, the constraintlibrary 205 may include constraints that are associated with the paymentrules. Some constraints may be associated with default values. Someexamples of the constraints include frequency of payment, currencyassociated with payments, etc.

For some example embodiments, the metaphors in a payment applicationframework may include actors, objects, and phases. The actors, objectsand phases may interact with one another in similar fashions acrossmultiple payment applications developed using the payment applicationframework 200. The payment applications may be developed to processdifferent types of payment transactions.

Metaphors: Actors

FIG. 3A is a diagram illustrating an application of the metaphors in apayment scenario, in accordance with some example embodiments. In thisexample, diagram 300 includes sender 305, receiver 310, and paymentfacilitator (or payment network) 315. The sender 305, the receiver 310,and the payment facilitator 315 are considered to be actors thatparticipate in payment transactions within the payment applicationframework 200.

A/ Sender

For some example embodiments, the sender 305 is an account holder of anaccount with the payment facilitator 315. Payments are to be debitedfrom an account of the sender 305. The sender 305 may represent anyperson, persons or entity who actually owns the account. The sender 305may also represent any person, persons, entity, or entities who havereceived approval to access the account of behalf of the actual owner.The sender 305 may be associated with one or more payment transactions.For some example embodiments, the sender 305 may be associated with anemail address related to the payment facilitator 315. For example, thepayment facilitator 315 may be PayPal, Inc. of San Jose, Calif., and anemail address related to PayPal, Inc. may be SenderID@PayPal.com. Forsome embodiments, an email address may be substituted with a mobilephone number or other such independent references to an account. Forsome example embodiments, there may be multiple senders 305 sendingpayments to a single receiver 310 in a payment transaction. This paymentscenario is referred to as aggregate payments.

B/ Receiver

For some example embodiments, the receiver 310 is an account holder ofan account with the payment facilitator 315. The receiver 310 mayrepresent any person, persons or entity who actually owns the account.The receiver 310 may also represent any person, persons, entity, orentities who have received approval to access the account of behalf ofthe actual owner. The receiver 310 may be associated with one or morepayment transactions. For some example embodiments, the receiver 310 maybe associated with an email address related to the payment facilitator315. For some example embodiments, there may be multiple receivers 310receiving payments from a single sender 305. This payment scenario isreferred to as split payments. For some example embodiments, there maybe multiple senders 305 and multiple receivers 310 in a paymenttransaction.

C/ Payment Facilitator

For some example embodiments, the payment facilitator 315 may receivepay request 320 from the sender 305. The pay request 320 may have one ormore line items describing the pay request in detail. The paymentfacilitator 315 may process the pay request 320 and may cause payment325 to be sent from an account of the sender 305 to an account of thereceiver 310. The payment facilitator 315 may enable the sender 305 touse different payment instruments. For example, the payment instrumentsmay include credit cards, debit cards, checking accounts, savingsaccounts, etc.

FIG. 3B is a diagram illustrating another application of the metaphorsin a payment scenario, in accordance with some example embodiments. Thepayment scenario described in this example may also be referred to aspayment extension. Diagram 390 includes sender 305, receiver 310, payrequest 350, and payment 355. For some example embodiments, the paymentapplication framework 200 may enable the payment 355 to be sent from afirst payment facilitator or payment network 360 to a second paymentfacilitator or a payment network 365. The payment facilitator 360 andthe payment facilitator 365 may be the same payment facilitator, or theymay be different payment facilitators. Similarly the “from” paymentnetwork and the “to” payment network may be the same payment network, orthey may be different payment networks. Some example of the paymentnetworks may include Automated Clearing House (ACH), Debit, Swift andvirtual currencies. In this example, the payment networks may also beconsidered as an actor that participates in the payment transactionswithin the payment application framework 200.

Although the following discussions use examples that refer to paymentsprocessed by a payment facilitator, it should be noted that thediscussions may also apply to one or more payment facilitator(s) and/orone or more payment network(s).

Metaphors: Objects

For some example embodiments, the objects may include pay requests, paykeys, and parameters associated with the pay requests and the pay keys.The pay requests may include information that defines a payment. The paykeys may be encrypted and may be used to request for approval or toindicate approval. As will be described, the approvals may be associatedapproval flows or pre-approval flows. The parameters may be included inhypertext transfer protocol (HTTP) messages. The HTTP messages may besent between the payment applications and may be processed by thepayment facilitator.

Referring to the example illustrated in FIG. 3A, the pay request 320 mayinclude an amount, information about a sender, information about areceiver, and a currency. The pay request 320 may also include otherrelated information such as, for example, transaction fee. Thetransaction fee is the fee charged by the payment facilitator 315 toprocess the payment transaction. The transaction fee may be paid by thesender 305 or the receiver 310.

The pay request 320 is sent to and processed by the payment facilitator315. The payment facilitator 315 may issue a pay key in response toreceiving the pay request 320. The payment facilitator 315 may send thepay key to the sender 305. The pay key may be used for approval. Forsome example embodiments, the pay request 320 is not processed until thesender 305 approves the pay request 320. The sender 305 may provide anapproval (or an indication of approval) based on an approval flow. Itmay be noted that the indication of approval received from the sender305 may either be a positive approval or a negative approval.

A pay key is uniquely associated with a pay request and may be used insubsequent payment transactions that are related to the pay request. Forsome example embodiments, a pay request waiting for an approval from thesender 305 may expire if the approval is not received after apredetermined period of time. An extension may be issued to prevent thepay request from expiring. An example of the pay key is illustrated aspay key 420 in FIG. 4A.

For some example embodiments, an approval may be provided by the sender305 before a payment is made. This is referred to as pre-approval. Inpre-approval situations, a pre-approval request may be created and sentto the payment facilitator. The payment facilitator may process thepre-approval request and may return a pre-approval key. Subsequently, apay request along with the pre-approval pay may be sent to the paymentfacilitator for processing.

For some example embodiments, the pre-approval key may be issued for onetime future payment or for a set of recurring future payments. Apre-approval key may be unique to a pre-approval request. The sender 305may provide a pre-approval based on a pre-approval flow. Thepre-approval flow may include of a set of rules. For some exampleembodiments, a pre-approval request may expire after a predeterminedperiod of time unless it is extended. An example of the pre-approval keyis illustrated as pre-approval key 465 in FIG. 4B.

The payment facilitator may perform functions to handle the approvalrequests and the pre-approval requests. The payment facilitator may alsoperform functions to handle other payment-related requests. Some ofthese functions may be required in every payment transaction, while somemay be optional. Without limiting the services and/or capabilities ofthe payment facilitator, the following table (Table 1) highlights someexample functions.

Service or Capability Name—Usage

TABLE 1 Pay - used in individual payment transaction. GetPayStatus -used to determine the status of a payment. GetPreApproval - used to getapproval for a future one-time or recurring payment.GetPreApprovalStatus - used to determine if a sender has approved a -pre- approval request. Capture - used to capture funds that have beenreserved for a payment. Partial payments may not be allowed, but withinsplit payments the capture of a particular segment or transaction of thepay request is possible. Refund - used in complex split paymentscenarios where refunds from multiple receivers are to be triggered allat once the refund function is used. This function may require thirdparty access right. A refund transaction can be executed by the receiverby calling the Refund function. The receiver would pass in a Pay Key andthe passed in refund amount to be refunded to the sender. InteractiveVoice Response (IVR) Approval - used to trigger payment facilitator'sIVR service to call a registered payment facilitator user's mobile phonenumber to get approval for a payment. GetPayRequestDetails - used to getinformation about a pay request based on a pay key. A pay key may bemapped to to one or more transaction. GetPreApprovalRequestDetails -used to get information about a pay request based on a pre-approval key.

Metaphor: Phases

FIG. 4A is a diagram that illustrates phases that are included in themetaphors, in accordance with some example embodiments. Diagram 400illustrates phases that may be part of the metaphors of the paymentapplication framework. There may be two phases. One phase is referred toas a pay phase 405, the other is referred to as an approval phase 410.During the pay phase 405, constraints may be defined and presented tothe payment facilitator 315. During the approval phase 410, an approvalmay be provided by the sender 305 approving the withdrawal of funds froma sender's account with the payment facilitator 315. As will bedescribed in FIG. 4B, a variation of the approval phase 410 is apre-approval phase 455.

For some example embodiments, the pay phase 405 may occur before theapproval phase 410. An example is a simple checkout scenario where a payrequest is followed by an approval by the sender 305. As illustrated,the pay request may include a pay key 420 as a parameter. Operationsassociated with the approval phase 410 may be based on an approval flow.The approval flow may direct the sender 305 to a web site of the paymentfacilitator 315. The web site of the payment facilitator 315 may providean interface for the sender 305 to provide information necessary for anapproval. For example, the sender 305 may be a customer purchasing anitem at a merchant's web site. The sender 305 may be redirected from themerchant's web site to the web site of the payment facilitator. Thisredirection may be via a Uniform Resource Locator (URL) link associatedwith an interface presented by the web site of the payment facilitator(e.g., PayPal web site). Based on the sender 305 providing the approvalfor payment, the sender 305 may be redirected back to the merchant's website. In this scenario, a redirect URL link (e.g., link to themerchant's web site) may be sent as a parameter, and the sender 305 isredirected to a specified page of the merchant's web site followingcompletion of the approval flow.

For some example embodiments, the approval phase 410 may be associatedwith approval notification flows. An approval notification flow may usea notification URL link as a parameter. The notification URL link may beassociated with a merchant. For example, when the sender 305 providesthe approval, the merchant is notified so that the purchase transactionof the sender 305 at the merchant's web site can proceed to a next step.The merchant in this example is in the role of the receiver 310. Forsome example embodiments, the approval phase 410 may include sending anotification to the sender 305 when the funds are transferred out of thesender's account. This may be performed via email, wirelesscommunication, or any other form of communication that may enablenotifying the sender 305. A similar notification may also be sent to thereceiver 310.

FIG. 4B is a diagram that illustrates an example of a pre-approvalphase, in accordance with some example embodiments. Diagram 450illustrates a pre-approval phase 455 and a pay phase 460. In apre-approval scenario, the pre-approval phase 455 may occur before thepay phase 460. The pre-approval phase 455 may be based on a pre-approvalflow.

A pre-approval request may be initiated and sent to the sender 305. Thepre-approval request may be initiated by a receiver (e.g., a merchant)310. A pre-approval key 465 may also be sent. The sender 305 may reviewthe pre-approval request via a pre-approval interface associated withthe payment facilitator 315. The sender 305 may provide the receiver 310the pre-approval. As described above, the pre-approval key 465 may beunique and may be associated with the pre-approval request for one timeor for recurring future payments. For some example embodiments, thepre-approval key 465 may be sent using encrypted data.

Constraints

The constraints may include rules that may be used by the developers tomore efficiently develop payment applications. The rules may beimplemented in the payment flows. The payment flows may be associatedwith the approval flows and/or the pre-approval flows. Parameters may beused with the payment flows. The parameters may have default values. Forsome example embodiments, some of the parameters may be used in thepayment flows with their default values unchanged. The following table(Table 2) illustrates an example summary of the payment flows that maybe used.

TABLE 2 Pay → Approval Pre-Approval → Pay Pre- A pre-approval request isApproval submitted to the payment processing logic of a paymentfacilitator. The pre-approval request is processed. A pre- approval keyis returned. A sender is directed to the pre-approval flow with thepre-approval key as a parameter. Payment A pay request is submitted by Apay request is submitted a receiver to the payment along with thepre-approval processing logic of the key to the payment paymentfacilitator. The pay processing logic of the request is processed and apayment facilitator. The pay pay key is returned to the request isprocessed. The requester (receiver). payment is processed. Approval Asender is directed to an approval flow with pay key as a parameter. Thesender provides an approval, and the payment is processed.

In order for a receiver 310 to use the payment flows, the receiver 310may need to have access to services provided by the payment facilitator315. As described above, having access may enable the receiver 310 tosend the pay requests 320 to the payment facilitator 315. In situationswhen the sender 305 provides a pre-approval for a payment, the sender305 may implicitly provide the receiver 310 (the party who initiated thepre-approval request) access to the account of the sender 305 on behalfof the sender 305. This may be limited to a time duration when thepre-approval request is active. For some example embodiments, thereceiver 310 may initiate a pay request only to reserve funds. In thosesituations, only operations associated with the reserve funds may becompleted, and the transfer of funds may wait until there is a capture(described above). The capture may include the pay key as a parameter.

Constraints: Approval Flows

FIG. 5 is a flow diagram that illustrates an example of an approvalflow, in accordance with some example embodiments. An approval flow mayinclude rules to send the pay request 320 and to get the sender 305 toprovide an approval for the pay request 320. The process in diagram 500may start at block 505.

At block 505, a pay request 320 is received by the sender 305. The payrequest 320 is associated with a pay key 420. The pay key 420 may beencrypted for security. The pay key 420 may be sent to the sender 305via a web page redirect, email, short message services (SMS) messages,etc. The pay key 420 may enable the sender 305 to retrieve the specificinformation about the pay request 320. For some example embodiments, theapproval flow may be associated with an approval interface showing thespecific details of the payment based on the pay request 320. Theinterface may be presented to the sender 305. For example, the sender305 may be directed to a web page associated with the interface. The webpage may be part of a web site associated with the payment facilitator315. The sender 305 may need to log in. This is illustrated in block510.

After the sender 305 logs in, the specific information about the payrequest 320 may be displayed. At block 515, the sender 305 may reviewthe pay request 320. At block 520, the sender 305 may provide anapproval. Based on the sender 305 providing the approval, the processmay be completed. The sender 305 may be directed back to a web page thatcauses the pay request 320 to be initiated.

Constraints: Interactive Voice Response (IVR) Approval Flows

Interactive Voice Response (IVR) is a technology that is used in mobileapplications via application programming interfaces (APIs). The IVRapproval flows may be used to get an approval from a sender 305 via amobile phone of the sender 305. The sender 305 may need to have thesender's phone number verified by the payment facilitator 315. For someexample embodiments, the payment facilitator 315 may include processinglogic that places calls to the sender 305 using the sender's phonenumber that was previously registered with the payment facilitator 315.As illustrated in FIG. 5, the pay request 320 and the pay key 420 may besent to the sender 305 for approval. However, instead of directing thesender 305 to a web page, the IVR system may call the sender 305 on thephone to get the approval. The sender 305 may use a personalidentification number (PIN) and provide the approval via the sender'sphone.

Constraints: Pre-Approval Flows

FIG. 6 is a flow diagram that illustrates an example of a pre-approvalflow, in accordance with some example embodiments. A pre-approval flowmay be used to approve the constraints offered in future one-time orrecurring payments. The process in diagram 600 may start at block 605.At block 605, a pre-approval request is received by the sender 305. Thepre-approval request may be received with a pre-approval key 465. Thepre-approval key 465 may be encrypted for security. The pre-approval key465 may be sent to the sender 305 via a web page redirect, email, shortmessage services (SMS) messages, etc.

For some example embodiments, the constraints included in thepre-approval request may need to be negotiated between the sender 305and the receiver 310 separate from the pre-approval flow. For someexample embodiments, the pre-approval flow may be associated with apre-approval interface showing the specific details of the pre-approvalrequest. The pre-approval interface may be associated with the paymentfacilitator 315 and may be presented to the sender 305. For example,this may be performed via a URL and the sender 305 may be directed to aweb page associated with the URL. The web page may be part of a web siteassociated with the payment facilitator 315. The sender 305 may need tolog in. This is illustrated in block 610. At block 615, the sender 305reviews the details of the pre-approval request. At block 620, thesender 305 may provide the pre-approval. Having the pre-approval mayallow the receiver 310 to receive future payments without having tosubmit a pay request.

For some example embodiments, a pre-approval provided by the sender 305may be canceled by the sender 305. This may be performed via apre-approval management interface of the payment facilitator 315. Thepre-approval management interface may list all the pre-approvalsprovided by the sender 305. The pre-approval management interface mayenable the sender 305 to select and to cancel one or more pre-approvals.

The pre-approval flows may be different from the normal approval flowsbecause the approval phase takes place before the pay phase and becausea single pre-approval can be applied to multiple payments. Thepre-approval flows may be applied to many different payment scenarios(e.g., split payment, checkout, send payment, etc.). Following are someexample constraints that can be applied to a pre-approval flow:

-   -   Max amount per execution    -   Max amount for all executions (sum)    -   Total number of times this pre-approval can be used to process a        payment.    -   The frequency of use (per day, month, and year)    -   Expiration date    -   Specify a receiver (by email address)    -   Specify the sender or receiver to pay the fees        The max amount and the expiration date parameters may be used to        reduce the risk involved in payment transactions associated with        the pre-approval flows.

Send Money Application

FIG. 7 illustrates an example of a send money scenario, in accordancewith some example embodiments. In this scenario, the sender 305 wants toinitiate a payment transaction to send money from the sender's accountwith the payment facilitator to a receiver 310. A send money scenario isoften associated with peer-to-peer transactions and may or may not needpre-approval.

At block 705, the sender 305 sends in a pay request. The sender 305 mayneed to have access to the payment facilitator 315 to submit the payrequest. In this example, the sender 305 may be either the actualaccount holder or someone who has rights to access the account of behalfof the sender 305. The payment facilitator 315 processes the pay requestand generates a pay key.

The sender 305 is then directed to an approval interface by the approvalflow with the pay key as a parameter. This may be though a web pageredirect, email, SMS message, or any other method that may include thesending a URL. The approval interface may be associated with the paymentfacilitator 315. Based on the sender 305 providing the approval, thepayment is processed, as illustrated in blocks 710 and 715. Optionally,if notification is requested and specified in the pay request, anotification message may be sent to the receiver 310 and/or the sender305.

An example of a send money scenario may include making an online paymentfor a utility bill. During the pay phase, a person (sender) visiting aweb site of a utility company (receiver) to make a payment for theutility bill. The web site of the utility company may make a programmingcall (pay request) with the details of the payment to the paymentfacilitator. A pay key is generated. The pay key may be sent to theutility company During the approval phase, the person is redirected fromthe web site of the utility company to a web site of a paymentfacilitator (e.g., PayPal) with the pay key and a redirect URL asparameters. The person is taken through an approval flow and approvesthe payment. The person is then redirected back to the web site of theutility company using the URL parameter. Payment is then transferredfrom the person's account to an account of the utility company. Theaccount of the utility company may be with the payment facilitator.

It may be noted that this example covers a send money scenario, and thusit may not be necessary to perform any reserve funds functions. However,if the reserve funds functions are required, this information would beincluded in the pay request. The reserve funds would then be performedafter the approval is provided. Subsequently, recapture functions mayneed to be performed to transfer the funds from the person's accountwith the payment facilitator.

The utility company may also want to use the pay status functions tocheck on the status of the payment. This may be performed by makinganother programming call to the payment facilitator to check on the paystatus of the payment. The programming call includes the pay key as aparameter, and the return status from the programming call may includeapproval information and funds transfer information. A paymentnotification may be sent to the utility company web site if thenotification option is included in the pay request.

In certain situations, the send money scenarios may be associated withthe pre-approval flow. These scenarios may be referred to aspre-approval send money. This may occur when a sender provides thepre-approval and access to send money from the sender's account in thefuture with restrictions. The sender 305 may create a pre-approvalrequest with constraints of the payment and send the request to thepayment facilitator 315. A pre-approval key is then generated by thepayment facilitator 315, and the sender 305 is taken through thepre-approval flow to view and create an agreement for the pre-approvalpayments. Subsequently, the sender 305 (or someone acting on thesender's behalf) may submit a pay request and send the pay request alongwith the pre-approval key to the payment facilitator 315. Based on thesender providing the approval, the payment is transferred. Anotification may also be included in the pay request to notify thesender 305 when the payment is transferred.

Checkout Application

FIG. 8 illustrates an example of a checkout scenario using the paymentapplication framework, in accordance with some example embodiments. Acheckout scenario may differ from a send money scenario because it isusually initiated by the receiver 310. The checkout scenarios may bereferred to as merchant flows or ecommerce transactions. Anotherdifference between the checkout scenario and the send money scenario isthat the send money scenario involves less interaction between thesender 305 and the receiver 310 than a checkout scenario. In thecheckout scenario, it is assumed that either digital goods or goodsavailable to ship immediately are available.

In this scenario, a consumer (sender 305) may indicate to a merchant(receiver 310) at a merchant's web site that the consumer wants to makea purchase. A common example would include the consumer filling ashopping cart on the merchant's website and selecting a checkout cart.The merchant then creates a pay request and send it to paymentfacilitator 315, as illustrated in block 805.

At block 810, a pay key is received from the payment facilitator 315.The merchant then redirect the consumer to the web site of the paymentfacilitator 315 with the pay key as a parameter, as illustrated in block815. The consumer is taken through an approval flow and approves thepayment, as illustrated in block 820. The fund is then transferred tothe merchant, as illustrated in block 825.

In certain situations, the checkout scenarios may be associated with apre-approval flow, referred to as pre-approval checkout. This occurswhen a consumer (sender) and a merchant (receiver) agree to apre-approval payment scenario by, for example, filling out a form on theweb site of the merchant. The merchant then creates a pre-approvalrequest with the constraints of the payment and then sends it to thepayment facilitator 315. A pre-approval key is received from the paymentfacilitator 315. The consumer is then redirected to the paymentfacilitator 315 and taken through a pre-approval flow. The consumer thenviews and creates the agreement to the pre-approval payments.Subsequently, the merchant may generate a pay request and send the payrequest with the pre-approval key to the payment facilitator 315 forpayments. A pay key may be sent to the merchant by the paymentfacilitator 315.

Split Payments

FIGS. 9A-9B illustrate examples of split payment scenarios, inaccordance with some example embodiments. A split payment scenarioprovides the ability for a single payment to be divided amongst multiplereceivers(s). In this situation, there may be multiple paymenttransactions but only a single pay key. The split payment scenario mayinclude parallel payment scenarios (illustrated in FIG. 9A) and chainedpayment scenarios (illustrated in FIG. 9B).

Referring to FIG. 9A, a single pay request may be used to transfer fundsfrom one sender 905 to multiple receivers 920-930. In this example,since there are three receivers 920, 925 and 930, there may be threeseparate transactions. In parallel payments, it may not be necessary todesignate a primary receiver. The sender 905 or any of the receivers920-930 can initiate the pay request. This is advantageous in situationswhen one receiver desires to make a pay request with a reserve fundsfunction while another receiver is designated to use the capturefunction. When it is time for the sender to review the pay request andto provide the approval, all segments or transactions within a parallelpayment may need to be visible for the sender 905 to approve.Accordingly, the receivers 920-930 are the merchants of record for allparallel payment scenarios.

An example of a parallel payment scenario includes a consumer whopurchases goods/services from multiple vendors in a shopping mall andpay for the goods/services in one checkout flow. The sender 905(consumer) may be redirected to a payment facilitator 935 and may onlyneed to provide one approval even though there are multiple receivers920-930 (vendors) involved. When the approval is provided by the sender905, the funds may be transferred to the accounts of each of thereceivers 920-930. It may be noted that the approval flow in theparallel payment scenarios with multiple receivers may involve the sameoperations (e.g., pay request, pay key, redirecting, approval, andpayment) as the approval flow for a single receiver. The difference isthat the payments are split to three receives in the parallel paymentscenarios. The details of how much to pay each of the receivers 920-930may be included in the parameters of the pay request and is based on thecost of the items purchased from the particular vendor. In the situationwhen one of the receivers 920-930 needs to cancel an item, a refund isprocessed for the amount associated with the item being canceled. In thesituation when one of the payment transactions fails (e.g., due toinsufficient funds), then a default action may include reversing orrolling back all payment transactions.

Referring to FIG. 9B, the chained payment scenario may be different thanthe parallel payment scenario because of the special circumstancessurrounding refunds, fees, and funds movement. This is because themovement of the funds to the primary receiver may need to happen beforethe funds are transmitted to the additional receivers. The chainedpayment scenarios may include a primary receiver 940 who first receivesall of the funds for the payment transaction. After the paymenttransaction completes, the funds are then moved into one or moresecondary receiver's accounts. For some example embodiments, the chainedpayment scenario may only have a single primary receiver 940 sending toa single group of additional receivers 945-950. For some exampleembodiments, a limit may be placed on a number of receivers (primary andsecondary receivers) for any given pay request. The sender 905 of thepayment transaction in a chained payment scenario may only see theprimary receiver 940 in the approval flow and any payment transactionhistory. Accordingly, the primary receiver 940 is the merchant of recordfor all chained payment scenarios.

An example of a chained payment scenario includes a broker who receivesfunds on behalf of the service providers. The broker is the primaryreceiver 940, and the service providers are the secondary receivers945-950. An example of a broker may be Travelocity.com which providesauthorization for all aspects of a travel package including airlineportion, hotel portion, event portion, etc. Each of these portions maybe associated with a different service provider. The secondary receivers945-950 may need to provide the primary receiver 940 third-party accessto their accounts in order to transfer payments into their accounts.This may also allow the primary receiver to issue refunds to the sender905 on behalf of the secondary receivers 945-950.

During the pay phase, the sender 905 (consumer) visits the web site ofthe primary receiver 940 (e.g., Travelocity.com). The sender 905 selectsa package that includes the services (e.g., hotel, car rental, flightinsurance, tour packages, etc.) provided by the secondary receivers945-950. The primary receiver 940 creates a pay request and sends thepay request to the payment facilitator 935. A pay key is generated andprovided by the payment facilitator 935 to the primary receiver 940.

During the approval phase, the primary receiver 940 redirects the sender905 to the payment facilitator 905. The sender 905 reviews the payrequest and provides the approval based on an approval flow. The pay keyis sent along with a redirect URL to return to the web site of theprimary receiver 940. Based on the sender 905 approving the payment, thesender 905 is redirected back to the web site of the primary receiver940 using the redirect URL. The funds are then transferred from thesender's account to the account of the primary receiver 940. The fundsare then sent from the account of the primary receiver 940 to theaccounts of the secondary receivers 945-950. It may be noted that all ofthese accounts may be associated with the payment facilitator 905.

Computer System

FIG. 10 shows a diagrammatic representation of a machine in the exampleform of a computer system 1000 within which a set of instructions, forcausing the machine to automatically perform any one or more of themethodologies discussed herein, may be executed. In alternativeembodiments, the machine operates as a standalone device or may beconnected (e.g., network) to other machines. In a network deployment,the machine may operate in the capacity of a server or a client usermachine in server-client user network environment, or as a peer machinein a peer-to-peer (or distributed) network environment. The machine maybe a server computer, a client user computer, a personal computer (PC),a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), acellular telephone, a mobile device, a palmtop computer, a laptopcomputer, a desktop computer, a personal digital assistant, acommunications device, a wireless telephone, a land-line telephone, acontrol system, a camera, a scanner, a facsimile machine, a printer, atelevision, television cable a pager, a personal trusted device, a webappliance, a network router, switch or bridge, or any machine capable ofexecuting a set of instructions (sequential or otherwise) that specifyactions to be taken by that machine.

Further, while a single machine is illustrated, the term “machine” shallalso be taken to include any collection of machines that individually orjointly execute a set (or multiple sets) of electronically-codedinstructions to perform any one or more of the methodologies discussedherein.

The example computer system 800 includes a processor 1002 (e.g., acentral processing unit (CPU), a graphics processing unit (GPU), orboth), a main memory 1004 and a static memory 1006, which communicatewith each other via a bus 808. The computer system 1000 may furtherinclude a video display unit 1010 (e.g., a liquid crystal displays (LCD)or a cathode ray tube (CRT)). The computer system 1000 also includes aninput device 1012 (e.g., a keyboard), a cursor control device 1014(e.g., a mouse), a disk drive unit 1016, a signal generation device 1018(e.g., a speaker) and a network interface device 1020.

The disk drive unit 1016 includes a machine-readable medium 1022 onwhich is stored one or more sets of electronically-coded instructions(e.g., software 1024) embodying any one or more of the methodologies orfunctions described herein. The instructions 1024 may also reside,completely or at least partially, within the main memory 1004, thestatic memory 1006, and/or within the processor 1002 during executionthereof by the computer system 1000. The main memory 1004 and theprocessor 1002 also may constitute machine-readable media.

The instructions 1024 may further be transmitted or received over anetwork 1026 via the network interface device 1020.

Applications that may include the apparatus and systems of variousembodiments broadly include a variety of electronic and computersystems. Some embodiments implement functions in two or more specificinterconnected hardware modules or devices with related control and datasignals communicated between and through the modules, or as portions ofan application-specific integrated circuit. Thus, the example system isapplicable to software, firmware, and hardware implementations.

While the machine-readable medium 1022 is shown in an example embodimentto be a single medium, the term “machine-readable medium” should betaken to include a single medium or multiple media (e.g., a centralizedor distributed database, and/or associated caches and servers) thatstore the one or more sets of instructions. The term “machine-readablemedium” shall also be taken to include any medium that is capable ofstoring, encoding or carrying a set of instructions for execution by themachine and that cause the machine to perform any one or more of themethodologies of the present invention. The term “machine-readablemedium” shall accordingly be taken to include, but not be limited to,solid-state memories, optical and magnetic media, and carrier wavesignals.

The illustrations of embodiments described herein are intended toprovide a general understanding of the structure of various embodiments,and they are not intended to serve as a complete description of all theelements and features of apparatus and systems that might make use ofthe strictures described herein. Many other embodiments will be apparentto those of skill in the art upon reviewing the above description. Otherembodiments may be utilized and derived therefrom, such that structuraland logical substitutions and changes may be made without departing fromthe scope of this disclosure. FIGS. 1 to 10 are merely representationaland may not be drawn to scale. Certain proportions thereof may beexaggerated, while others may be minimized.

Although the present invention has been described with reference tospecific example embodiments, it will be evident that variousmodifications and changes may be made to these embodiments withoutdeparting from the broader spirit and scope of the invention.Accordingly, the specification and drawings are to be regarded in anillustrative rather than a restrictive sense.

The description includes terms, such as “up”, “down”. “upper”, “lower”,“first”, “second”, etc. that are used for descriptive purposes only andare not to be construed as limiting. The elements, materials,geometries, dimensions, and sequence of operations may all be varied tosuit particular applications. Parts of some embodiments may be includedin, or substituted for, those of other embodiments. While the examplesof dimensions and ranges are considered typical, the various embodimentsare not limited to such dimensions or ranges.

The Abstract is provided to comply with 37 C.F.R. §1.74(b) to allow thereader to quickly ascertain the nature and gist of the technicaldisclosure. The Abstract is submitted with the understanding that itwill not be used to interpret or limit the scope or meaning of theclaims. In the Detailed Description, various features are groupedtogether in a single embodiment for the purpose of streamlining thedisclosure. This method of disclosure is not to be interpreted asreflecting an intention that the claimed embodiments have more featuresthan are expressly recited in each claim. Thus, the following claims arehereby incorporated into the Detailed Description, with each claimstanding on its own as a separate embodiment.

1. A computer-implemented method of facilitating payment applications,the method comprising: associating a payment transaction with a sender,a receiver, and a payment facilitator; associating a transfer of a valuefrom the sender to the receiver with a pay request; associating thepayment transaction with at least one approval flow to enable the senderto approve the pay request; associating a pay key with the pay request,the pay key being used in approving the pay request; and enabling thepayment facilitator, using one or more processors, to complete thepayment transaction responsive to receiving an indication of approval ofthe pay request by the sender based on the approval flow.
 2. (canceled)3. The method of claim 1, wherein the indication of approval includes apositive approval or a negative approval.
 4. The method of claim 1,wherein the pay request is initiated by the receiver or the sender. 5.The method of claim 1, wherein the pay request is initiated from awebsite associated with the receiver.
 6. The method of claim 5, furthercomprising: directing the sender from the web site associated with thereceiver to a website associated with the payment facilitator; andenabling the sender to review the pay request and to provide theindication of approval.
 7. The method of claim 6, further comprising:based on receiving the indication of approval from the sender, directingthe sender to the web site associated with the receiver.
 8. The methodof claim 1, wherein the enabling the payment facilitator to complete thepayment transaction responsive to receiving the indication of approvalfrom the sender comprises transferring the value to the receiver whenthe indication of approval is a positive approval.
 9. The method ofclaim 8, wherein the transferring the value to the receiver comprisesdebiting the value from an account of the sender, the account of thesender associated with the payment facilitator.
 10. The method of claim9, wherein the transferring the value to the receiver further comprisescrediting the value to an account of the receiver.
 11. The method ofclaim 10, wherein the receiver includes a first receiver and a secondreceiver.
 12. The method of claim 11, wherein the crediting the value tothe account of the receiver comprises crediting the value to an accountof the first receiver and at least a portion of the value from theaccount of the first receiver to an account of the second receiver. 13.The method of claim 11, wherein the crediting the value to the accountof the receiver comprises crediting a portion of the value to an accountof the first receiver and another portion of the value to an account ofthe second receiver.
 14. The method of claim 10, further comprisingenabling the value to be reserved in the account of the sender beforethe crediting the value to the account of the receiver.
 15. The methodof claim 1, wherein the enabling the payment facilitator to complete thepayment transaction responsive to receiving the indication of approvalfrom the sender further comprises notifying the sender about thetransferring of the value.
 16. The method of claim 15, wherein thenotifying is based on a notification flow.
 17. A machine-readablestorage medium comprising instructions, which when implemented by one ormore processors performs a method, the method comprising: associating apayment transaction with a sender, a receiver and a payment facilitator;associating a transfer of a value from the sender to the receiver with apay request; associating the payment transaction with at least oneapproval flow to enable the sender to approve the pay request;associating a pay key with the pay request, the pay key being used inapproving the pay request; and enabling the payment facilitator tocomplete the payment transaction responsive to receiving an indicationof approval of the pay request by the sender based on the approval flow.18. A computer-implemented method comprising: associating a paymentfacilitator with a sender and a receiver in a payment transaction, thepayment facilitator configured to transfer a value from an account ofthe sender to the receiver based on a pay request; enabling generationof a pay key associated with the pay request, the pay key used inapproving the pay request; enabling the sender to approve the payrequest based on an approval flow or a pre-approval flow; and enablingthe payment facilitator, using one or more processors, to completetransferring of the value using at least one default parameter from aset of default parameters.
 19. The method of claim 18, wherein the setof default parameters include at least a currency parameter.
 20. Themethod of claim 18, further comprising enabling generation of apre-approval request associated with the pre-approval flow.
 21. Themethod of claim 20, further comprising enabling generation of apre-approval key responsive to the generation of the pre-approvalrequest.
 22. (canceled)
 23. The method of claim 18, wherein the payrequest is initiated by the sender, and wherein, responsive to the payrequest being initiated by the sender, the sender is redirected from awebsite associated with the receiver to a website associated with thepayment facilitator.
 24. The method of claim 23, further comprising,responsive to the sender approving the pay request, enabling the senderto be redirected from the website associated with the paymentfacilitator to the website associated with the receiver.
 25. The methodof claim 18, wherein the account of the sender is with the paymentfacilitator.
 26. The method of claim 18, wherein the value istransferred from the account of the sender to an account of thereceiver.
 27. The method of claim 26, wherein the account of thereceiver is with the payment facilitator or with a third party paymentnetwork.
 28. The method of claim 27, wherein the receiver includes aprimary receiver and a secondary receiver, and wherein the value istransfer to an account of the primary receiver, and wherein at least aportion of the value is transferred from the account of the primaryreceiver to an account of a secondary receiver.
 29. The method of claim27, wherein the receiver includes a primary receiver and a secondaryreceiver, and wherein the value is transfer partially to an account ofthe primary receiver and partially to an account of the secondaryreceiver.
 30. The method of claim 26, further comprising enabling thevalue to be reserved in the account of the sender before the value istransferred to the account of the receiver.
 31. The method of claim 26,further comprising notifying the sender after the value is transferredout of the account of the sender and based on a notification flow. 32.The method of claim 31, wherein the notifying is performed via atelephone number or an email address associated with the sender.